1. Field of the Invention
The present invention relates to copying data between storage devices, and more particularly to an apparatus, method and computer program for Point-In-Time data copying.
2. Description of the Related Art
A Point-in-Time copy (PIT) is a feature supported on various storage devices that allows a user or an automated process to make nearly instantaneous copies of entire logical volumes of data or datasets. A copy of a source storage device is made on a target storage device. The copies are immediately available for both read and write access. Typically, but not necessarily, a background copy process is also started that copies the data on the source storage device to the target storage device in portions known as grains. An example of a PIT implementation is IBM® FlashCopy® (IBM, and FlashCopy are registered trademarks of International Business Machines Corporation in the United States, other countries, or both).
Typically, a PIT may copy an entire source storage device or selected grains of the source storage device. An ‘incremental PIT’ copies only those grains of the source storage device that have changed since the previous PIT. Therefore, keeping track of differences in both source and target storage devices is necessary. Also typically, a full grain is copied, however alternatively, a partial grain may also be copied.
Typically, PIT operations are controlled using a PIT relationship between the source and the target storage devices. A PIT relationship map indicates differences between the source and the target storage devices. Typically, a PIT relationship map is maintained as a bitmap, comprising information about the grains, for example, whether a background copy of the grain has been completed, or whether a write has been made to the source or to the target. When a PIT is ‘triggered,’ the contents of the source storage device are immediately available from the target storage device.
After a PIT is triggered, but before the background copy has been completed, reads and writes are directed to the appropriate location to ensure data integrity. For example, before a host write to the source storage device, the existing data is copied to the target storage device. If a read is requested from the target storage device before the appropriate grain has been copied, the read is redirected to the corresponding grain of the source storage device. If a write is made to a grain on the target storage device, the background copy of the corresponding grain from the source storage device is not performed. If the data is found on the target storage device the grain is said to be “split.” A PIT ‘completes’ when all contents of the source storage device are available directly from the target storage device.
In an incremental PIT, after the PIT copy is triggered, differences between the source storage device and the target storage device are recorded. In an incremental PIT only grains that are different are copied from source storage device to target storage device. During the PIT, if a host writes to the source storage device the grain is copied to the target storage device, and the grain is marked as different so that it will be recopied when the PIT is next triggered. Difference recording continues after all grains have been split and is used to reset the split bitmaps when the PIT is triggered again.
A cascaded PIT environment may also be established with target storage devices of one PIT relationship, acting as a source storage device of a further PIT relationship. In a cascaded PIT environment the contents of the source storage device of a PIT relationship may be modified by the actions of another PIT relationship using the source storage device as a target storage device. Therefore, when using incremental PIT in cascaded environments, normal difference recording cannot always record the differences accurately and has to take a pessimistic view of what data has changed when a PIT relationship is restarted.
For example, one PIT copies storage device A to storage device B (A→*B), and another PIT copies storage device B to storage device C (B→*C). PIT relationship A→B is triggered, followed by PIT relationship B→*C. After the PITs complete, PIT relationship A→B and PIT relationship B→C continue to record differences between A and B, and between B and C respectively, ready for the next time the PITs are triggered. When A→B is re-triggered, the changes in B need to be reflected in the difference recording of B and C.
One solution is to turn off the difference recording of PIT relationship B→*C, marking all of the data different. All the data is recopied when PIT relationship B→C is re-triggered. This solution is simple but reduces the effectiveness of incremental PIT within a cascaded environment.
Another solution is to analyze the bitmaps of PIT relationship A→B to determine data that should be recopied in PIT relationship B→*C. This solution requires the modification of the difference bitmaps of many PIT relationships if a storage device is a source of multiple PIT relationships. In addition, the data that should be copied for PIT relationship B→C is not minimized, unless PIT relationship A→B completes. Therefore, when PIT relationship A→B is re-triggered, any data changed on source A is marked as different for PIT relationship B→*C. If PIT relationship A→B is subsequently stopped before the new data is copied from A→B, the data remains marked as different in B→C even though the data on the storage devices is identical.
Therefore, there is a need in the art to address the aforementioned problem.